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(57) ABSTRACT 

A single sign -on (SSO) mechanism to enable a given user to 
access a target application on a target resource in a distrib- 
uted computer enterprise. One or more configuration direc- 
tives each identifying a given logon process and any asso- 
ciated methods required to access the target application on 
the target resource are stored in a preferably global- 
accessible database (CIM). For each of a set of users, a 
preferably global- accessible database (PKM) stores user- 
specific and application-specific information enabling the 
user to access and logon to one or more target resources. 
During a particular session, a logon coordinator (LC) 
mechanism coordinates given user information with the 
configuration directive to enable the given user to perform a 
given action with respect to the target application without 
specifying the given logon process and the application- 
specific information. 

22 Claims, 6 Drawing Sheets 
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COORDINATING USER TARGET LOGONS specific logon scripts. This is how many "homegrown" 

IN A SINGLE SIGN-ON (SSO) single sign-on systems work today This technique is the 

ENVIRONMENT least extendible design because it ties passwords (and logon 

target code) to each machine the user uses. It is also hard to 

BACKGROUND OF THE INVENTION 5 maintain passwords in this design because passwords need 

to be changed both in the applications and in the logon 

1. Technical Field scripts. For a mobile user, the scripts need to be present on 
The present invention relates generally to accessing het- a ll machines the user might use. The overall security of this 

erogeneous networks and reducing costs by increasing pro- approach is thus very weak. 

ductivity for end-users and system administrators in an 10 Mother target logon alternative involves building in all 

enterprise computer environment. me logon methods for every p0S sible target to which any 

2. Description of the Related Art user may desire to logon. This "hardcoded" approach 
With sprawling client-server systems growing daily, assumes that all workstations and applications are config- 

applications and information are spread across many PC ured similarly and do not change. Because the logon meth- 

networks, mainframes and minicomputers. In a distributed 15 ods are built into the solution, changes made to the logon 

system environment connected by networks, a user must methods require changes to the actual solution itself. This 

access many database systems, network systems, operating approach is costly and also is not very extensible, 

systems and mainframe applications. To use these systems These known approaches to secure password storage/ 

and applications, the user must issue separate sign-on com- management and target logon have yet to provide an 

mands for each specific system or application. Indeed, it is 20 adequate single sign-on solution. The present invention 

not unusual for a user to encounter ten or more different addresses and solves this problem, 
login sessions during a working shift, and these often are 

different interfaces with different userid and authentication BRIEF SUMMARY OF THE INVENTION 

information, usually passwords. This places the user under The present invention implements a single sign-on (SSO) 

a significant burden to remember and maintain this infor- 25 mechanism that coordinates logo is to local and remote 

mation. resources in a computer enterprise with preferably one ID 

It would be quite beneficial to provide a single sign-on and password. 

(SSO) tool to enable authorized users to perform one initial More specifically, this invention provides a single sign-on 

sign-on to access a variety of networks, systems and appli- (SSO) framework that allow users to sign on to a client 

cations. A single sign -on system should provide secure system one time entering ones password. The SSO frame - 

storage of user passwords, support for more than one user work then signs on to other applications on the user's behalf, 

password, as well as support for multiple target logon -phe § S q framework supports storage of all passwords 

methods. Each of these issues presents varying design anc j k evs belonging to a user in secure storage (e.g., either 

considerations. ^ m i oca [ storage, a centralized password service, a smartcard, 

With respect to the first issue, there are multiple or the like), so that the user needs to remember only one ID 

approaches to storing and managing passwords. One and password. Upon authentication, the SSO mechanism 

approach is to use the same password for all accessible securely retrieves all the passwords for a user from the 

systems/applications. This technique may weaken system secure storage and automatically (i.e. without additional user 

security, however, because a compromised password in any m intervention) issues sign-ons to each system/application the 

of the systems or applications compromises the user's user is authorized to access, 

privileges on these systems and applications at the same The system framework preferably includes a number of 

time. Further, different sign-on mechanisms may have their modules including a configuration information manager 

own distinctive password requirements and, thus, it is prob- (CIM), which includes information on how to logon to the 

lematic to use the same password for multiple targets. 45 applications configured on a given machine, a personal key 

Another approach to storing and managing passwords is manager (PKM), which includes information about users, 

password-mapping, which refers to using the user's primary systems and passwords they use to logon to those systems, 

password to encrypt all the user's secondary passwords. The and a logon coordinator (LC), which retrieves the user's 

encrypted passwords are stored in a local storage space passwords from PKM and uses them in conjunction with 

accessible to the user (e.g., a local file, a readable/writable 50 target-specific logon code to log users onto all their systems, 

smartcard, and the like). Once the primary password is preferably without and additional user intervention, 

verified, the local system authentication module obtains the The CIM facilitates adding new logon methods as needed, 

passwords for other sign-on systems and applications by Information is preferably stored in the CIM using "tem- 

decrypting the mechanism-specific encrypted password with plates" referred to as program template files (PTFs). A given 

the primary password. The security of this password- 55 PTF thus is used to create entries in the CIM. This template 

mapping scheme assumes that the primary password is the mechanism enables an application vendor to specify how to 

user's strongest password, and it also depends on the secu- log onto a given application. Thus, independent software 

rity of the local storage for the secondary passwords. If the vendors and others can easily plug their applications into the 

secondary passwords are stored in an untrusted publicly SSO framework without writing a large amount of code, 

accessible machine, an intruder is provided with opportuni- 60 The SSO framework preferably implements a "data 

ties for potential attacks. Moreover, although this approach model" where information used to sign on to applications is 

is simple, the password file must be moved from machine to kept in the separate PKM and CIM databases. Preferably, the 

machine by the user to logon to more than one machine. PKM is globally accessible and stores user-specific 

The target logon alternatives also influence the single information, and the CIM is locally accessible and stores 

sign-on system design. In particular, the method used for 65 application-specific information derived from PTF files. In 

storing a user password heavily influences the design of operation, the logon coordinator (LC) accesses the PKM to 

target logon code. It is known to embed passwords in target obtain the user's information (e.g., which target systems and 
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applications to which the user can sign -on), as well as the Preferably, the server and client services components of 
passwords and keys for those systems/applications. The LC the SSO mechanism are implemented in a computer or 
then uses these passwords/keys, together with the target "machine/' For example, each server may be a RISC 
logon information found in the CIM, to sign-on to various System/6000® (a reduced instruction set or so-called RISC- 
target systems and applications. Sign-on is preferably based 5 based workstation) running the AIX((Advanced Interactive 
upon the target's own protocols and mechanisms as defined Executive) operating systsm, preferably Version 4 or greater, 
in the PTE Alternative servers include machines running Sun Solaris V 

Another objective of this invention is to allow applica- 2.5.1 or Microsoft Windows NT 4.0. 
tions to be plugged into the single sign-on (SSO) framework. Each client machine in the domain may be a computer 
According to the invention, preferably the program template 10 such as a desktop machine or laptop. A typical client 
file (PTF) is used to inform the single sign-on mechanism machine is an Intel x86 or Pentium® -based computer run- 
how to interact with a given application or subsystem to ning Windows *95 or greater operating system. Alternatives 
perform SSO-related operations. The PTF enables applica- include machines running OS/2® Warp 3.x or higher, or a 
tions to be plugged into the SSO mechanism without chang- Microsoft Windows NT workstation. Each client worksta- 
ing the SSO code itself and without requiring any programs 15 tion typically supports TCP/IP and may include a network 
to be written to plug into the new application. operating system (NOS). A typical client is a Novell Net- 

Still another more general objective of this invention is to ware client (for Netware logons), an OS/2 LAN Server client 

provide a framework-type SSO mechanism that enables any (for OS/2 LAN Server logons), an OS/2 Warp Server client 

kind of target to be user-specified. (for OS/2 Warp Server logons), or the like. These examples, 

The foregoing has outlined some of the more pertinent 20 however, are merely represertative and should not be con- 
objects of the present invention. These objects should be strued 10 limil the invention in any way. 
construed to be merely illustrative of some of the more Many different types of target systems/applications are 
prominent features and applications of the invention. Many accessed using the single sign-on mechanism. These include 
other beneficial results can be attained by applying the distributed applications, databases, printers, and other 
disclosed invention in a different manner or modifying the 25 resources throughout the enterprise. Representative systems 
invention as will be described. Accordingly, other objects and applications include, without limitation: 3270 and 5250- 
and a fuller understanding of the invention may be had by based applications, IBM OS/2 Lan Server 4.x and OS/2 
referring to the following Detailed Description of the pre- Warp Server, Novell Netware 3.x and 4.x, Microsoft NT 4.0 
ferred embodiment. Server, Databases (e.g., DB2, Oracle, Sybase, Informix, MS 

30 SQL Server), Lotus Notes 4.x, PeopleSoft applications, 

BRIEF DESCRIPTION OF THE DRAWINGS DCE applications written to conform to The Open Group 

For a more complete understanding of the present inven- (formerly known as the Open Software Foundation), and 

tion and the advantages thereof reference should be made to other applications. These examples, again, are merely rep- 

the following Detailed Description taken in connection with 35 resentative. 

the accompanying drawings in which: FIG. 2 illustrates the main components of the inventive 

FIG. 1 is a computer enterprise environment in which the single sign-on (SSO) mechanism of the present invention, 

present invention may be implemented; They preferably include an authentication module 21, a 

FIG. 2 is a block diagram of the main functional compo- configuration information manager (CIM) 22, a personal key 

nents of the inventive single sign-on (SSO) mechanism; 40 manager (PKM) 24, and a Logon coordinator (LC) 26. In 

FIG. 3 is a representative single sign-on transaction general, the authentication module 21 authenticates a given 

according to the present invention; user l ° me remainder of the single sign-on (SSO) mecha- 

. . . a • A _c r iL nism. On systems with local operating system security, the 

HG. 4 is a representative logon interface screen for the autheiltication mechamsm 21 ^ ly % mtegrated wim the 

i>i>U transaction ot MU. 3; Jocal QS amhentication n& authentication module prefer- 

FIG. 5 is a representative GUI screen identifying the ably supports different authentication mechanisms (e.g., 

systems/applications for a particular user; secret keVj smartcardS) pu bli c /private key, and the like). 

FIG. 6 is a high level illustration of the operation of the Thc configuration i n f ormat ion manager (CIM) 22 

logon coordinator (LC) of the SSO mechanism; indudes information on how to logon t0 the a ppi ica tion S 

FIG. 7 is a flowchart illustrating the LC operation; 5Q configured on a given machine. Preferably, a CIM is sup- 

FIG. 8 illustrates how the logon coordinator performs a ported on each client machine from which the SSO mecha- 

matching operation between PKM and CIM entries; nism is provided. A given CEM typically is not globally 

FIG. 9 is a flowchart of a change password operation; and accessible from other machines on the domain. Information 

FIG. 10 is a block diagram of a representative multiple in the CIM preferably is formatted according to a program 

SSO server implementation and a DCE Security Registry for 55 template file (PTF) 25, as will be illustrated below in more 

supporting the PKM data model. detail - CIM thus stores "configuration directives" iden- 
tifying the given logon process and the methods required to 

DETAILED DESCRIPTION OF THE access a particular application on the target resource. New 

PREFERRED EMBODIMENT logon methods nay be added using the PTF mechanism as 

FIG. 1 illustrates a portion of a distributed computer 60 De seen, 

environment domain 10 in which the present invention may The PKM 24 contains information about users, systems 

be implemented. The signal sign-on (SSO) mechanism com- and passwords they use to logon to those systems, 

prises both server 20 and client (runtime services) compo- Preferably, PKM 24 is a secure, globally accessible reposi- 

nents 14, 16 and 18. For purposes of illustration, each of tory that facilitates the single sign-on process. Although not 

these are illustrated as a computer. It is also assumed that 65 meant to be limiting, with respect to a given user, the PKM 

system users, log onto the domain via client machines in a (as will be described) preferably stores such information as 

known manner. a username, a set of one or more password(s), and any other 
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application environment-specific information such as Specific application information — describes interfaces 

domain name, hostname, application name, and the like. needed to perform operations like logon, logoff, and the 

Because this access information preferably is centralized in like; 

the PKM, users can access their target resources with one Program Preferences — indicates timeouts and retry 

sign-on from any workstation. They can also manage their 5 counts; and 

passwords from this one repository, as will also be seen. Interface directory— client-spiecific information on how 

To this end, the logon coordinator 26 functions generally to locate the application interface code, 

to retrieve the user's passwords from the PKM and uses The expected runtime flow of a user interacting with the 

them in conjunction with the target specific logon code single sign-on (SSO) mechanism is illustrated in FIG. 3 and 

(identifiable from the CIM entries) to log users onto all (or io described as follows. At step 1, a user either logs in to a local 

some subset of) their systems, preferably without any addi- operating system (if required by the local operating system) 

tional user intervention. As will be described in more detail or logs on via a logon interface (if local logon is not required 

below, the LC also preferably maintains state information by the operating system). A representative logon interface 

for a given user and application, called a "user target", to screen is illustrated, for example, in FIG. 4. The user's local 

help coordinate and execute future operations. is logon enables the authentication module (GSO Auth) on the 

According to the invention, the single sign-on mechanism local machine (if supported) to authenticate the user (step 2) 

preferably uses a "data model" where information used to to the authentication service that is integrated with the 

sign on to applications is kept in two separate databases. The password storage service. 

first database is the PKM 24, which is preferably a global A successful authentication riggers the single sign-on 

database and is thus accessible from all client machines in a 20 graphical user interface (GUI) to display (at step 3) the 

given domzlin. The PKM 24, as noted above, keeps user systems/applications the user is able to logon to and the 

configuration information. The second database is the CIM status of the logon process. A representative GUI screen 

22, which is preferably a local database and is thus acces- display is illustrated in FIG. 5. The GUI also calls the logon 

sible only from the current client machine. The CIM need coordinator on the local machine (at step 4) to retrieve the 

not be merely a local database, however. Each client 25 user's configuration information and target configuration 

machine from which the SSO support is provided runs a information. As described, the logon coordinator gets the 

CIM. Thus, multiple instances of CIM 22 are illustrated in user's information (which target systems and applications 

FIG. 2. Likewise, each client machine preferably also runs the user can signon to) and the passwords and keys for those 

an instance of the logon coordinator 26. systems/applications from the personal key manager. If the 

Thus, for example, the PKM 24 contains user-specific 30 personal key manager is implemented as a remote service 

application data which includes: (or if the necessary information is located remotely), the 

Target name— uniquely identifying a user "target" personal key manager client (at step 5) gets the information 

Target type^pecifies what type of "a P plication"this tar- in a secure fashion (i.e. the passwords/keys are encrypted for 

* t . g . transmission). The credentials returned from the authentica- 

^ S . ' WA .. . c , n 35 tion module are used by the personal key manager client to 

Domam/Host/Apphcation name^specifies application ^ J q ^ Qn {Q ^ mech * nism fc the 

information, specific for this target; ^ whQ ^ passwords 

User ID-specifies user id on target; ^ bgon coordinator (step then uses these pasS words/ 

Key information^pecifies the user's key (password) on ke y S and ^ tar g et logon information fmmd in the configu- 

the target; 4q rat i 0 n information manager (CIM) to sign-on to various 

User preferences— specifies user specific information for targel S y Ste ms and applications, based upon the targets' own 

this target; and protocols and mechanisms. The logon coordinator prefer- 

Preferred program name — specifies a preferred CIM entry a bly provides status information about the state of the logons 

to use with this target. and also allows some targets to be launched asynchronously 

The personal key manager 24 enables a given SSO user to 45 (after the initial sign-on processing has completed), 

manage all the passwords the user possesses in a secure and This mechanism allows for different passwords for dif- 

effective manner. According to the invention, each ferent target systems and applications without requiring the 

application, server, or system to which a user needs an user to remember all such passwords. The user remembers 

ID/password pair to logon is defined as a "target". Using a only one password to log into the mechanism, which then 

GUI interface, the user creates a target in PKM correspond- 50 performs the subsequent logging into the different system by 

ing to each real target to which the user can logon, and the acquiring the secret keys from the secured key manager 

user may create as many (or as few) targets as the capability (local or remote) This SSO mechanism enhances security as 

of a specific PKM implementation allows (or that the user W ell ^ ease 0 f use. It also enables the user to access existing 

desires). Independent of any implementation, a generic system without having to create or to modify existing user 

PKM application programming interface (API) preferably is 55 definitions on those systems. As will be seen, the mechanism 

used by the SSO framework to create a new target, to update also allows a user to change his or her single sign-on 

a target's data, to query a target's information (with or password without requiring changes of the target keys/ 

without passwords), and to delete an existing target. passwords or vice versa. Target password changes can be 

The second database, the CIM 22, preferably contains made to one or more selected target systems, 

entries derived from the program template files (PTFs). This 60 pro 6 is a high level illustration of the operation of the 

database contains application (i.e. program) specific logon coordinator 26. FIG. 7 is a flowchart illustrating one 

information, which includes (for example): preferred single sign-on method, which may be suitably 

Target type — specifies what type of "application" the implemented in a computer program. The routine begins at 

program is, i.e. what type of "application" can be step 40 when a user 30 (at a workstation 32) requests a logon 

accessed as a target using the program; 65 to a given application (Target 1) 33. In response, the routine 

Default program — indicates if the CIM entry is the default continues at step 42 with the logon coordinator 26 issuing a 

program to use for a target of the given target type; query to the PKM 24 for the information regarding the user's 
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"key" (which, as described above, may include the 
username, password, and any other application 
environment-specific information as described above). At 
step 44, the information is returned to the logon coordinator. 
Then, the routine continues at step 46 with the LC issuing a 
query to the CIM to obtain the program information. At step 
48, the program information is returned to the LC. The 
information retrieved from the CIM 22 for the particular 
application determines how to logon to the application (e.g. 
what type of invocation to make, what actual invocation, and 
the like). At step 52, the logon coordinator 26 substitutes 
given data received from the PKM into substitution vari- 
ables in the invocation strings returned from the CIM. In 
particular, the logon coordinator performs a matching opera- 
tion; for each PKM target entry, the coordinator determines 
whether there is a corresponding CIM entry. If so, step 52 
binds the two entries together. This is illustrated in FIG. 8. 
At step 54, the logon coordinator 2E invokes the logon 
method(s) defined by and stored in the CIM. This completes 
the processing. 

Generalizing, the logon coordinator (LC) thus takes the 
data from the personal key manager (PKM) and the direc- 
tives in the CIM and interprets the data, together with 
current state information, to perform a given action. Such 
action is carried out with respect to the users' systems and 
applications and includes for example, a logon operation, a 
change password operation, or a logoff operation. 

If the user requests a change password operation, the LC 
makes the correct invocation to change the password and 
coordinates the password update in the PKM. Continuing 
with the above -described example (involving Target 1) a 
representative flowchart of this function is illustrated in FIG. 
9. By way of brief background, the logon coordinator 
preferably maintains state information for a given user and 
application, a "user target", to help coordinate and execute 
future operations. By looking at the current state of a user 
target and interpreting data in the PKM entry and the CIM, 
the LC can determine which operations are required to 
satisfy an SSO request. For example, the CIM can specify 
that a user should be logged on to an application before 
performing a change password operation. Therefore, the LC 
would keep track of the logon state of a user target to 
determine what operations are required to satisfy a change 
password request. If the user were not logged on to the 
application, the LC would perform a logon operation and 
then perform the change password operation. 

The flowchart of FIG. 9 is illustrative of the process. The 
routine begins at step 60 when the user desires to change a 
password for his/her Target 1. At step 62, the routine gets 
Target 1 information from the PKM; here, the target type is 
Appl. The routine then gets the corresponding program of 
the given type from the CIM at step 64. A test is then 
performed at step 66 to determine whether the user has to be 
logged on to change his/her password. If not, the routine 
continues at step 68 and the user password is changed. If, 
however, the outcome of the test at step 66 is positive, a test 
in performed at step 70 to determine whether the user is 
logged on. If the outcome of the test at step 70 is positive, 
the routine branches to step 68; otherwise, the user is first 
logged on at step 72. This completes the processing. 

A combination of the data model described and the LC 
implementation thus provides "free seating" support. Free 
seating means that the user does not have to specify a 
particular program on the client when using the SSO mecha- 
nism to log onto a particular target. The free seating method 
allows the user to install any program on his or her client 
machine and then have the logon coordinator pick the 
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appropriate cone to logon to the target. The LC preferably 
does this by examining the "target type" associated with the 
programs on the client and the target the user is trying to 
access. If the program has the same target type as the target, 

5 then the LC knows it can use that program to access that 
target. This means that the user can logon to a target if any 
program on the system matches the target type, rather than 
needing a fixed program to do the logon. 

For example, a user may have a target "HOST1" of type 

10 "3270 Emulator." On the machine on the user's desktop, the 
user may have the "telnet3270" program, which is of the 
type "3270 Emulator" available to logon to HOST1. On the 
user's laptop, the user may have the IBM Personal Com- 
municator program available, which is also a 3270 Emulator, 

35 to logon to that target. Wren the user uses the SSO mecha- 
nism on the desktop machine, the LC will use telnet3270 as 
the 3270 Emulator to logon to HOST1; on the laptop, IBM 
Personal Communicator will be used. These examples, of 
course, are merely representative of the inventive free seal- 

20 ing support concert. 

The generic PKM data model described above may be 
implemented in many ways including, without limitation, 
DCE client/server, a real smartcard, a soft (disk-based) 
virtual smartcard, or the like. One advantage of using an 

25 implementation-independent PKM API as described herein 
is that different mechanisms may be pluggable without any 
modification to other SSO application programs. Moreover, 
multiple mechanisms can be configured on one machine and 
a user has the option to choose a specific one. 

30 A representative PKM is implemented in a known DCE 
Security Registry architecture conforming to The Open 
Group DCE Standard. Familiarity with DCE security 
mechanisms is presumed in the following discussion. 
FIG. 10 illustrates the basic PKM architecture, which may 

35 be distributed across multiple machines in the domain. In 
particular, it is first assumed that multiple SSO servers 
lOOa-rt are configured and running in the domain. Multiple 
PKM servers are replicated on different machines, e.g., for 
performance and scalability. Each server preferably per- 

40 forms the same functions. Thus, preferably there is no 
master/slave relationship among them. As also seen in FIG, 
10, user specific target configuration data and target pass- 
words (together, PKM data) of SSO users are stored in a 
database 102, which may be a DCE extended registry 

45 database (ERA). When the PKM server modifies data in the 
master registry database 102, data consistency between the 
master and slave registries is achieved automatically by the 
data duplication mechanism in registries. However, no 
encryption facilities are usually provided by the registry for 

50 data stored in the database 102. To avoid target passwords 
being revealed to SSO administrators (or others), the pass- 
word field is preferably encrypted with a master key man- 
aged by the PKM server before the whole target is stored in 
the database 102. Further, because multiple SSO servers can 

55 be configured for load balancing, a local copy of this master 
key preferably exists in each one of SSO servers. The master 
key thus is generated automatically by one server machine 
and "waited to be pulled" by other servers when they are up 
and running. A simple "group" mechanism provided by 

6D DCE (or some other similar mechanism depending on the 
architecture implementation) is used to tell which servers 
possess the valid master key. 

The PKM data model elements were described above. The 
groups preferably include: target name, target attributes, key 

65 information, user configuration and target class. The target 
name is the identifier used to distinguish a target from other 
targets. The target attributes include target type, domain/ 
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host/application names and target user name. The key infor- The program template file (PTF) as previously described 

mation contains the password of the user for the target and is a convenient mechanism for telling SSO how to interact 

the type of the key derived from the password (e.g., a public with a given application or sub-system to perform SSO- 

key, a secret key, or the like), The user configuration is the related operations. The key benefit of the PTF is that it 

user's own configuration preference when the user logons to 5 enables applications to be plugged into SSO without chang- 

and logoffs from the target. The target class defines whether ing the SS o code itself and without requiring any programs 

the target is a password-based target or a passticket-based t0 ^ written to plug into he new application, 

target. If it is a passticket-based target, a passticket-protected M described abovCj prp file preferably contains the 

(C - g '-^ C S a PP u licat T sc ™ r ' s ^me must usually be following rclcvarit information: 

specified. The above-described generalized data model , n n . , • i_. 

enables all kinds of targets to be defined through the PKM 10 Pro S ram name identifies the program/application being 

API. Thus, in certain circumstances, not all the fields/ integrated. 

attributes may have values for each target because only a Target type specifies the type of target the PTF describes, 

subset of attributes may be sufficient or meaningful for The target type is used by other parts of SSO to specify 

defining a specific, real target. In addition, because a pas- an application of this type. 

sticket for a protected server is dynamically-generated on 15 Methods describes how SSO should perform SSO opera- 
demand, no password is required to be stored with a Hons, 

passticket-based target. A stanzfl for each method exists which describes how sso 

PKM is pre erab y implemented as a client/server appli- kr Qn method ^ 

cation in a distributed computing environment (e^. Open £ £ ^ for ^ ^ 

Group DCE) as described above. The PKM server prefer- 20 * / ___ . 

ably implements all PKM functions. In this illustrative DCE ^£2?™ (S ™ FI ° )l 

implementation, all target data is stored in DCE registry's \ 

ERA and the server accesses the data on behalf of each user capability=CLI 

on a client machine. Therefore, the PKM API is mapped to interface=Logon.exe $U $P /D:$D 

a set of remote procedure calls (RPCs) on each client 25 rCl3 success=0 

machine using the DCE RPC mechanism. RPCs with dif- rc_error=2100-2900 3010-3240 

ferent protection levels (e.g., privacy or integrity) and dif- In th ~ cxample , ^ me thod SSO would use to logon to LAN 

ferent properties (e.g., idempotent or at-most-once) are Server is specified by the capability (CLI for command line 

employed to pass data, depending on the API's security and interface> ^ for application programming interface). The 

semantic requirements. When the server receives a client s 30 actual command to bc executed is specified in the interface, 

request, a thread is created to access the data in the ERA. If The symbols $U( $P and £D rcpr esent username, password 

the request is a create, update, or delete operation, a write to and domain> respectively. It is expected that SSO will 

the master registry is required. If the request is a query rcplace those symbols with the username, password and 

operation, a read from any slave registry is sufficient to carry domain the u&er is tfying to logon [Q> as i[ldicated m rqc. 8. 

out the operation. Continuing with this DCE example, if a 35 Retum codes frQm (he interface are assoc iated with buckets 

password-based target is queried, the password is retrieved (rc _ succesS( rc _error, etc.), allowing the appropriate action 

from ERA. If a passticket-based ticket is queried, one more tQ be taken based the bucket into which the retum code falls 

RPC is used to retrieve the secret key shared between the Qther melhods prcfcrably include START, LOGOFF, and 

PKM server and the passticket server. The server then CHANGE_PASSWORD . Additionally, the PTF describes 

generates the passticket based on the secret key and other 40 additional app]ication behavior such as whe ihcr the appli- 

information configured for - the target, cation needs to be started prior to logon, whether the 

One of ordinary skill will appreciate that the above PKM LOGON method must be invoked before the CHANGE, 

functions may also be implemented in other distributed PASSWO rd method, location information where the appli- 

environments besides Open Group DCE. Thus, the illustra- cadon existg Qn tfae h ica] machine) and method retry and 

tive embodiment should not be construed to limit the present 45 t j meout va ] ues 

invention. . . The following is a representative PTF: 

Summanzing, the SSO approach described above pro- rMAINl 

vides several advantages. The framework-based SSO J . . . 

mechanism enables all kinds of targets to be defined for any def ^^^^ r ?^ ) ; ^ * enclosed *° 

user. Different PKM implementafions can be( pluggable 50 quote- SSO uses th^ as the default for program name in the 

using the generic API without any changes to the programs ™f ™S ram user mterrace. 

using the PKM service. The described implementation (e.g., default_program name = example 

within a DCE architecture) makes user authentication, fonnat_v«sion (required) .should rot be changed. SSO uses 

secure communication and data management mush easier. 11 10 determine which version of SSO you used to create this 

One design consideration of a single sign-on system is the 55 P ro S ram tem P late - If need t0 s P ecif V V our own versions > 

network authentication between a single sign-on user and use comments to do so. 

the single sign-on centralized server, as well as the secrecy format__version-L0 

of passwords and keys transmitted across networks. These target_type (required): is case sensitive. target_type must 

two requirements can be achieved by utilizing the authen- match the [TARGET_TYPE] defined in a file called a 

tication and message encryption functions provided by any 60 schema file. Use a predefined SSO target type or create a 

security service (such as DCE's Kerberos or NetSP's new one. To create a new one, specify it with no spaces and 

KryptoKnight). To make the SSO components portable to no quotes to guarantee uniqueness: 

different security environments, the design and implemen- type@DNS-name 

tation of the SSO components preferably is independent of target_type= 

the underlying authentication protocols and encryption 65 [SETTINGS] 

mechanisms. This is a significant advantage of the present logon^sequence (required) : defines the sequence in which 

invention. the program expects start and logon operations to occur. 
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Valid values are; 

prompt: The program preferably requires the start and logon 
to be performed in the same operation. The START section 
is ignored. The LOGON section is required. 
start__required: The program preferably is started before 
logon can occur. Both START and LOGON sections are 
usually required. 

no„start required: The program can be logged on without 

being started first and can be started without subsequently 
logging on. Both START and LOGON sections are optional. 
logon_sequence« 

change_password_sequence: typically required, defines 
the sequence in which the program expects the logon and 
change password operations to occur. Valid values are: 
logon_required: The program requires a logon before the 
password can be changed. Be aware of the following: 
If the target is not logged on and change_password_ 
sequence=Logon__required, the LOGON_AND__ 
CHANGE_PASSWORD interface string is used to log 
on to the target and change the password. 
If the target is not logged on, the change_password_ 
sequence is set to Logon_required, and there is no 
Logon_and_change_password interface string, the 
LOGON interface string is used to log on to the target, 
and then the CHAN GE_PASSWORD interface string 
is used to change the password. 
If the target is already logged on, the 
CHAN GE_PASS WORD 
interface string is used to change the password. 
no_logon_required: The program allows a password to be 
changed whether the user is logged on or not. The 
CHAN GE__PASSWORD interface string is used to change 
the password. 

change_password_sequence- 

You should define either minimum_timeout or maximum^ 
timeout. They both default to 0, which implies an infinite 
wait. If you define both, define minimum_timeout to be less 
than maximum_timeout. 

minimum_Jimeout is the minimum amount of time, in 
seconds, that SSO should wait for a function to complete 
before returning. 

minimum__timeout applies to command line interfaces only. 
It is intended to be used for targets that return successfully 
right away but require initialization time before a subsequent 
operation, such as LOGON, can be performed, 
maxiraum_timeout is the maximum amount of time, in 
seconds, that SSO should wait for a function to complete 
before returning. maximum__timeout applies to both API 
and command line interfaces. It is intended to prevent a hang 
situation when a running process does not return when 
expected, 

minimum_timeout= 
maximum timeout- 

directory (optional): defines the directory containing the files 
specified in the interface string definitions. In most cases, 
this is the default installation directory. If you do not specify 
a default directory here, you should specify the fully- 
qualified file names in the interface string definitions, 
directory a 

retries (optional): defines the number of times to retry an 
operation before returning an error. Retries are attempted, 
for example, when a return code defined in the rc_error 
return code bucket is received. 
retries= 

The Interface Sections 

Interface sections define the interfaces SSO will use to 
invoke your program to access the particular target type 
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defined in the [SETTINGS] section. In general, the inter- 
faces define either an API call or a command line interface 
and the parameters expected. You can use substitution 
variables in the parameters to represent target- and program- 
5 specific information needed to invoke the function. 
Substitution Variables 

Substitution variables are reserved variables for target - 
specific information. The following substitution variables 
are commonly used for all target types: 
10 SU The target userid. 
$P The target password. 

$N A user's new target password. SSO uses this value only 
in the CHANGE_PASSWORD and LOGON_AND_ 
CHANGE_PASSWORD interfaces, 
15 The following substitution variables preferably are used in 
some combination to identify the target system. Their exact 
meaning is defined in the schema file for the particular target 
type supported: 

SA The target application name. 
20 $D The target domain name. 
$H The target host name. 

$M, a reserved substitution variable, is a special message 
output parameter that lets you specify a text message that 
can be returned by the interface. SSO will write this message 
25 to the SSO log. This parameter may be used to develop 
wrapper code to improve the integration of a given program 
with SSO. It may be used to give the user information should 
the interface not complete successfully when invoked by 
SSO. 

30 Unreserved Program-Unique Variables 

Preferably, there are seven other substitution variables — $1 
through $7 — that allow one to specify other program- 
specific information. If any of these variables are used, a 
section in the program template file may be included to 

35 define them. 

The capability keyword describes the type of programming 
interface required to start the program supported by this 
program template. Valid values are: 
API16 for 16-bit APIs. 

40 API32 for 32-bit APIs. 
CLI for command line. 
For example, capability=API32 

The interface string defines how to invoke the API or 

command line interface for this function. 
45 Specifying an API Interface 

interface="<path-filename combo>function__return_type 

function_name (parml,parm2, . . . )" 

Specify the interface string, which preferably cannot be 

longer than 1024 characters, on one line. There are prefer- 
50 ably no continuation characters. Enclose the string in double 

quotes. Enclose the entire executable path and file name 

combination (path-filename combo) in less than 

(<) and greater than (>) symbols. The interface is _Syslem 

linkage. 

55 Here is a representative description of the interface param- 
eters: 

function_return_type«inl, uint, long, or ulong 
function_name is the API entry point, 
parml, parm2, and so on are parameters specified as: 
60 [parm„direction] parm_type parm_value 
[parm__direction]=[in] 
[out,max_is(size)] 

size is the number of bytes required to hold the output data 
from the function, such as $M in the example that follows. 
65 parm_type«int, int*, uint, uint*, short*, ushort*, long, 
long*, ulong, ulong*, char*, or uchar* 
parm_yalue=value 
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value is either a "value possibly containing spaces enclosed 
in double quotes" or a substitution variable. 
API Interface Example 
capability-AP332 

interface«"<c:\appl\logon_ops.dll>int appLogon([in]char* s 
stringval, [injushort $2, [injchar* $D, [out,max_is(512] 
char* $M)" 

Specifying a Command Line Interface 
cap ability =CLI 

interfaces" <path-filenarae combo>parml_value parm2„ 30 
value ..." 

Enclose the entire interface string in double quotes. Enclose 
the entire executable path and file name combination (path- 
filename combo) in the less than (<) and greater than (>) 
symbols. 

parml__value=varue 
parm2__value=value 

value is either a "value possibly containing spaces enclosed 
in double quotes" or a substitution variable. 
CLI Interface Example 
cap ability =CLI 

interface="<c:\ibmlan\netprog net2.exe>$3" 
Return Codes 

Identify the category into which the return codes fall. 
Specify return codes as: 

A list of return codes separated by commas 

A range of return code values 

A combination of both 
rc_success: The operation performed on the target was 
successful. 30 
rc__information: The operation performed on the target was 
successful and the target returns information in the form of 
a null -terminated character string. SSO logs this character 
string in the default error log. 

rc_chgpwd__error: A change password operation is neces- 35 
sary. SSO notifies the user. 

recredentials expired: The user's credentials to the target 
have expired. Certain types of targets have time limited 
credentials. If the credentials have expired, the user might 
have to reissue a logon to that target. 40 
rc_error: The operation performed on the target produced an 
error, but the operation is worth retrying. SSO retries the 
operation until it reaches the maximum number of retries 
specified when the program was added. SSO displays status 
messages to the user while it retries the operation and at the 45 
point when it reaches the maximum limit of specified retries. 
rc_severe_error: The operation performed on the target 
produced an error so severe that there is no recovery. SSO 
does not retry the operation. 

[START] 50 

[START] defines the interface to start the program. 

capability^ 

interfaces 

rc_success= 

rc_informationo 55 

rc_chgpwd_error« 

rc_credentials__expired» 

rc_error« 

rc_severe_error= 

[LOGON] 60 

[LOGON] defines the interface to log on to the target. 

capability^ 

interface o 

rc„success= 

rc__informau'on= 65 

rc_chgpwd_error= 

rc_credentials_expired= 



rc_error= 
rc__severe_error= 
[CHANGE ^PASSWORD] 

[CHANGE_PASSWORD] defines the interface to change 

the user's target password. 

capability^ 

interfaces 

rc_success» 

rc_information= 

rc_chgpwd_error- 

rc„credentials_expired* 

rc_error» 

r c_se v e re _e rro r = 

[LOGON_AND_CHANGE_PASSWORD] 

[LOGON_^AND_CHANGE_PAS SWORD] defines the 

interface to log on to the target and change the user's 

password. 

capability= 

interfaces 

rc_success= 

rc__information» 

rc_chgpwd_error=* 

rc credentials expired* 

rc__error= 

rc_severe__error«= 

[LOGOFF_FORCE] 

[LOGOFF_FORCE] defines the interface to force logging 

off of the target. 

capability- 

interface- 

rc_success- 

rc__information- 

rc__chgpwd_error- 

rc_credentials_expired- 

rc error- 

rc__severe__error- 
[LOGOFF_GRACEFUL] 

[LOGOFF_GRACEFUL] defines the interface to log off 

gracefully (without loss of data) from the target. 

capability- 

interface= 

rc_success= 

rc__information= 

rc_chgp wd „e r r o r = 

rc__credentials_expired= 

rc_error= 

rc_severe_erro r = 

Substitution Variables 

Use the unreserved substitution variables, $1 through $7, in 
the interface sections to represent program-specific infor- 
mation. Then, include a section, [$1], [$2], on so on, to 
define each one used. 

value =how is this specified? 

labels"text label" or ?77helps"text string" or 77? 

Define a value for each substitution variable using the value 

keyword. By using substitution variables, you simplify your 

interface sections. 

One can use substitution variables for information needed 
from the user. In this case, omit the value keyword or use it 
to specify a default value. Then, define values for the label 
and help keywords. SSO uses these to build a user interface 
(entry fields) for collecting the information from the user. 
SSO stores the value of the substitution variables, either 
specified or collected from the user, in the program infor- 
mation database on the client machine. 

Summarizing, single sign-on is facilitated by storing all 
the passwords and keys belonging to a user in secure storage 
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(either in local storage, a centralized password service, or in for each of a set of target resources having different logon 

a smartcard), so that the user needs to remember only one ID processes, storing configuration directives identifying 

and password. The single sign-on ID and password is then the given logon process and methods required to access 

used to authenticate the user. Upon authentication, the a particular application on the target resource; 

mechanism securely retrieves all the passwords for a user 5 for each of a M of sto ri ng user-specific information 

from the secure storage and automatically (without any that enables the user to access and logon to one or more 

additional user intervention) issues sign-ons to each appli- of ^ t resources; and 

cation the user is authorized to access. , . , «_ • 

Hie present invention provides a framework that allows du ™g a lo S on *! tem P l b y a f™ u ^ r r w rcs P cct t0 a 

the PKM and the CIM implementations to be separable from in tar B cl applicaUon on one of the set of target resources, 

the rest of the single sign-on code. The functions provided 10 coordinating given user information with at least one 

by the aforementioned components are preferably imple- given configuration directive to enable the given user to 

mented via a high-level API. Thus, a new implementation logon to the target application without specifying the 

(such as Lotus Notes) can be added without causing a major given logon process. 

redesign. This mechanism provides a logon coordination 2. The method as described in claim 1 further including 

framework so that each specific target can be easily plugged 15 the step of validating a user id/password of the given user 

into the single sign-on logon coordinator framework. This during the logon attempt. 

facilitates the support of the vast range of client server 3, The method as described in claim 1 further including 

targets. the step of storing state information associating the given 

The present invention enables efficient access to hetero- user w ^h the given target application, 

geneous networks at reduced costs to thereby increase 20 4 -jne me thod as described in claim 3 further including 

productivity for end-users and system administrators. These me step of using tne state information stored to facilitate 

advantages are achieved by enabling users to sign-on once access to the target application in a subsequent session, 

with a single ID and password to access business applica- 5 method as described in claim 3 further including 

tions and data. The design goals achieved are ease of use, lhe step 0 f using the state information to determine whether 

secure authentication of users, and logon coordination to 25 tne g i ven llSQr nas authority to perform a given operation, 

multiple applications. g Xhe method as described in claim 5 wherein the given 

The present invention provides numerous other advan- operation is a change password operation, 

tages. It is based on an easy to use interface, and provides a 7 method as described in claim 6 further including 

consistent look and feel across operating systems. The tool me step 0 f performing the given operation, 

is also advantageous in that it integrates with operating 30 8. The method as described in claim 1 wherein a particular 

system logons, is based on open standards, supports "one configuration directive is generated by a provider of a given 

time" passwords, and is capable of leveraging existing target application. 

security infrastructures. 9. A method of enabling single sign-on access to a target 

One of the preferred implementations of the various application on a target resource in a distributed computer 

modules described is as a set of instructions in a code 35 enterprise, comprising the steps of: 

module resident in the random access memory of a com- generating a configuration directive identifying a given 

puter. Some of the framework functionality is supported m log(m process and any associated methods required to 

a client machine, and some of the framework functionality acccss the target application on the target rcS0 urce; 

is supported in one or more servers. Until required by the ^ ^ q{ ^ ^ Qf g user-specific and 

computer, the set of instructions may be stored in another 40 plication _ specific information that enables the user to 

computer memory, for example, in a hard disk drive, or in ^ ^ ^ to Qne or mQre xcsomccs . and 

a removable memory such as an optical disk (tor eventual ° ... . 

use in a CD ROM) or floppy disk (for eventual use in a during » *««»> coordinating given user information 

floppy disk drive), or even downloaded via the Internet. with the configuration directive to enable the giver, user 

In addition, although the various methods described are 45 to V^otm a given action with respect to the target 

conveniently implemented in a general purpose computer application without specifying the given logon process 

selectively activated or reconfigured by software, one of and the application-specific information, 

ordinary skill in the art would also recognize that such 1° The method as described in claim 9 wherein the given 

methods may be carried out in hardware, in firmware, or in action is a user logon to a target resource 

more specialized apparatus constructed to perform the so 11. The method as described in cla,m 9 wherein the given 

required method steps. action a change password operation. 

Further, although the invention has been described in 12- The method as described in claim 9 wherein the 

terms of a preferred embodiment in a specific network configuration directive is defined by a template file, 

environment, those skilled in the art will recognize that the The method as described in claim 9 wherein the 

invention can be practiced, with modification, in other and ss configuration directive is stored in a local database, 

different network architectures with the spirit and scope of M. The method as described in claim 9 wherein the 

the appended claims. Moreover, the logon coordinator may user-specific and application-specific information is stored 

be useful in other than single sign-on (SSO) environments. in a database. 

Having thus described our invention, what we claim as 15- A system architecture for enabling access to a target 

new and desire to secure by letters patent is set forth in the 60 application on a target resource in a distributed computer 

following claims. enterprise, comprising: 

What is claimed is: means for storing at least one configuration directive 

1. A method of single sign-on to multiple target resources identifying a given logon process and any associated 

in a computer enterprise environment, wherein at least some methods required to access the target application on the 

target resources normally require a given logon process to 65 target resource; 

access applications on the target resource, comprising the means for storing user-specific identifying information for 

steps of: eacn of a set of users, the user-specific identifying 
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information enabling a given user to access and logon 
to one or more target resources; and 
means for coordinating given user-specific identifying 
information with the configuration directive to enable 
the given user to perform a given action with respect to 5 
the target application without specifying the given 
logon process. 

16. The system architecture as described in claim 15 
wherein the given action is a user logon to a target resource. 

17. The system architecture as described in claim 15 10 
wherein the given action is a change password operation. 

18. The system architecture as described in claim 15 
wherein the given action is a logoff from a target resource. 

19. The system architecture as described in claim 15 
wherein the means for storing the configuration directive is 15 
a database. 

20. The system architecture as described in claim 15 
wherein the means for storing the user-specific identifying 
information is a database. 

21. A computer program product in a computer- readable 20 
medium operable on a computer for enabling access to a 
target application on a target resource in a distributed 
computer enterprise, comprising: 

means running on the computer for storing at least one 
configuration directive identifying a given logon pro- 25 
cess and any associated methods required to access the 
target application on the target resource; 

means for retrieving user-specific identifying information 
for a given user to enable the given user to access and 
logon to one or more target resources; and 
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means for coordinating the retrieved user-specific identi- 
fying information with the configuration directive to 
enable the given user to perform a given action with 
respect to the target application without specifying the 
given logon process, 

22. A computer connectable in a distributed computer 
enterprise, comprising: 

at least one processor; 

a memory; 

a computer program supported in the memory and execut- 
able by the at least one processor for enabling access to 
a target application on a target resource in the distrib- 
uted computer enterprise, the computer program com- 
prising: 

means for storing in the memory at least one configu- 
ration directive identifying a given logon process and 
any associated methods required to access the target 
application on the target resource; 

means for retrieving user-specific identifying informa- 
tion for a given user to enable the given user to 
access and logon to one or more target resources; and 

means for coordinating the retrieved user-specific iden- 
tifying information with the configuration directive 
to enable the given user to perform a given action 
with respect to the target application without speci- 
fying the given logon process. 

***** 
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